Many different portable devices can communicate with a gateway device. The gateway acts as a bridge between the wireless portable devices and the wired computer networks, such as the Internet. A gateway device may include a standard server, with additional software that allows communications to be made between the portable devices, which may be wireless, and devices with which the gateway may be in communication.
Developers may write custom application software for the portable devices. It may be desirable to allow the application software to receive commands from the gateway device and perform an action, such as moving the portable device, providing a perceptible signal, resetting a sensor, collecting data from a sensor, or providing a communication to a device to which the portable device may be attached or in proximity. The application software in the device may provide a response, even if the response is only an acknowledgement of receipt of a command.
For example, the application software in the device may contain certain procedures such as functions, and some of these functions the developer may wish to allow other devices to call. The developer may have put a great deal of thought into the data structures in the such functions or other procedures, and the developer may wish to reuse those same data structures when the functions or other procedures are called remotely.
However, providing such a communication facility in the device that would allow functions or other procedures to be remotely called requires the developer to program a communications subsystem, a tedious and time-consuming task that many developers would rather avoid.
The communication facility in the device is not the only modification that would be required in such a system. It would also be necessary to provide a facility to allow the gateway device to receive such commands from external sources in an easy to use format. Conventional Web services provide such a format, but there are several of these formats, and it can be can be tedious to write conversion software for the gateway that will accept commands in any of several Web services formats, reformat such a command into a command to send to the device, send the command to the device, accept the response, reformat it into one of the Web services formats, and finally return the response to the originator of the command. Not only is the software to perform all of these functions tedious to write, but it can also require knowledge of communications techniques and Web services formats that the developer of the application software for the device may not wish to learn.
Furthermore, different types of devices and different gateways may each use their own data formats, making the conversion of any format on the gateway to any format on the devices, in order to allow any device to communicate with any gateway, an unwieldy problem.
If the device is a portable device, it can be desirable to provide such communications between the gateway and the device using wireless transmissions. Because bandwidth in wireless transmissions may be shared among multiple devices sharing the same frequency, and capacity of a wireless network may be smaller than that of wired transmissions, it can be desirable to conserve bandwidth when providing such wireless transmissions. The developer could attempt to more compactly communicate with the gateway, but again, this capability would require additional tedious custom programming that many developers may wish to avoid, and expertise that they may not have.
If the developer were to develop remotely callable procedure calls and gateway server software described above, significant testing may be required to ensure that the remote procedure calls and server communications software are compatible. For example, if the gateway converts a command it receives in one format into a remote procedure call using a format that is inconsistent with the format of the remote procedure call, a call placed by providing a command to the gateway won't cause the device to perform in the manner expected. This compatibility testing can be a bane to the programmers or software testers, who must test for every possible mistake, but when a few such mistakes inevitably are not caught, they can seriously disrupt operation of an entire system.
Not only do these two systems require strict compatibility, but there is a third area for potential incompatibility, which is the web services description that outside parties use to develop the commands they send to the gateway. Typically, a programmer will write the description, which again, must be tested. The compatibility testing between these three areas is not only time consuming and tedious to perform, but the errors that inevitably slip through can again cause the system to operate improperly, and problems can be difficult to identify.
The significant compatibility testing between these three areas is thus a major source of frustration and expense.
It can be desirable for any solution to use a flexible approach to allow the gateway or server software to be generated. Different gateways may use different compiler software and their operators may desire to use different types of web services or other similar approaches to provide the interface with the senders of the remote procedure calls. Thus, allowing sufficient flexibility to choose the type of interface, and type of compiler can be helpful.
Because the devices may be mobile, they may move in and out of range of different gateways at different times. Requiring every gateway to have interface software for every possible device can be a logistical nightmare. It would be desirable if the server software did not have to be installed on every gateway.
What is needed is a system and method that can add a communication facility to an application program, that can allow a developer to mark certain procedures in an application program as remotely callable, and that can accept commands in one or more Web services or other formats that can call such procedures using a data structure that is at least similar to that used in the procedure in the application program, can reformat them for compact transmission via a wireless network, provide them to a device for execution, and receive and reformat any response into the format of a Web service, and that can accommodate any format incompatibilities between devices and gateways, that allows the gateway software to be flexibly tailored for the server capabilities and interface desired, that can allow a gateway to interface to new devices without requiring the gateway to maintain software for every device, without requiring the developer to provide the additional custom programming of a communication facility or test for incompatibilities between the software on the gateway and software in the devices that run the procedure calls and between the gateway software and the description such as a web service description.